The running of a secure connection between two entities of a communication network passes by the initiation of a secure session based either on the SSL protocol or the TLS protocol.
Consequently, to establish such a session, the two entities use mechanisms that are supposed to ensure that the session created may not be hacked or spied on. Below, the operation of the SSL and TLS protocols will be described. Even though this description is more particularly dedicated to the TLS protocol, it also applies to the SSL protocol.
The TLS protocol is organised on the basis of a set of five software entities which work together, APPLICATION, HANDSHAKE, CCS, ALERT and RECORD. The “APPLICATION” entity refers to a software application that wishes to run a secure communication session (layer 7 of the OSI model). The “HANDSHAKE”, “CCS”, “ALERT” and “RECORD” entities (also called layers) are entities which are used as part of an application of the TLS protocol, of which a detailed description may be found under the reference “RFC 2246” by the IETF committee (“Internet Engineering Task Force”). Such an application of the TLS protocol is made at level 5 of the OSI model.
The architecture of an OSI stack may be described as follows: the layer managed by the “RECORD” entity (also called “RECORD” layer) transports the messages produced by the “APPLICATION”, “HANDSHAKE”, “CCS” and “ALERT” entities, by means of a 5 octet header which defines the entity generating the message, the version of the TLS protocol used and the length of the message. The message themselves also contain a header which indicates the type of the message and the length of the associated data. However, the structure of the “APPLICATION” messages is not defined by the TLS standard. Indeed, each application exchanges messages of which the structure is defined by the application protocol, as for the HTTPS (Hypertext Transfer Protocol Secured) protocol.
Consequently, an “APPLICATION” application uses the services offered by the TLS protocol which creates the confidentiality (encryption) of the data transported using the TCP (Transmission Control Protocol) protocol at the transport layer level.
The TLS secured channel is implemented in two steps, a phase for the authentication and calculation of the keys, followed by, if this is successful, a phase where a secured communication channel is used, using the set of keys previously determined.
The entity of the “HANDSHAKE” layer (also called “HANDSHAKE” layer) carries out the authentication and key calculation procedures. There are two authentication modes, the complete mode (called “Full Session”) and a rapid mode (“Session Resumption”). These two modes will be described in more detail later.
The “HANDSHAKE” layer negotiates the encoding and integrity algorithms used by the entity of the RECORD layer (also called “RECORD” layer), which are identified by a number called “cipher_suite”.
At the end of a successful authentication procedure, the “RECORD” layer determines a value called master_secret. Using two random numbers produced by the client entity (client_random) and the server entity (server_random) it calculates a set of keys (the keys_bloc), used for the encoding and the integrity of the data received and emitted:keys_block=PRF(master_secret,“key expansion”,server_random client_random);
PRF (Pseudo_Random_Function) is a function which generates pseudo random data; the symbol “|” indicates a concatenation operation.
In a simplified manner, the keys_bloc parameter is a couple of two pairs of keys (KcRx, KiRx) and (KcTx, KiTx) used respectively for the encoding (prefix Kc) and the integrity (prefix Ki) of the data received (suffix Rx) and emitted (suffix Tx).
The “CCS” layer (Change_Cipher_Spec) signals the modifications of the security parameters to the “RECORD” entity. It activates the start of the encoding and integrity procedures of the data, using the “keys_bloc” and “cipher_suite” parameters.
The entity of the ALERT layer (also called “ALERT” layer) signals the errors detected by the “HANDSHAKE” entity (in the case of authentication failure), or by the “RECORD” layer (detection of an integrity error, or an end of session).
The “RECORD” layer carries out four types of operations:                fragmentation of the data into blocks whose maximum size is 214 (16,384) octets;        an optimal compression of the data; this service is generally not carried out;        a generation of signatures (based on the HMAC algorithm, defined by the RFC 2104);        enciphering of the data.        
The set of parameters required for the operation of the “RECORD” layer is called “security_parameters” and further comprises the values of the “keys_bloc” produced by the HANDSHAKE entity.
The messages exchanged between the application layer and the layer TCP are encrypted and decrypted by the “RECORD” layer using a set of two pairs of keys (KcRx, KiRx) and (KcTx, KiTx) previously described.                The messages received by the “RECORD” layer are encrypted by the key KcRx ({M}KcRx) and given a HMAC(KiRx, M) signature associated to the KiRx key. The latter verifies the HMAC signature and provides the decrypted value to the application layer.        The messages issued by the application layer are encrypted by the “RECORD” layer using the KcTx ({M}KcTx) key and are given a HMAC(M,KiTx) signature associated to the KiTx key.        
When the cipher mode is activated, the RECORD layer operates as follows: a “MESSAGE” transmitted/received by an entity such as “HANDSHAKE” or “APPLICATION” is given a header containing three parameters: type, version, length. The complete “MESSAGE”, “HMAC signature” and “padding octets” is encrypted using the algorithm negotiated during the authentication phase and a key Kc.
The “HMAC” signature is calculated from the header, the “MESSAGE” and a frame number (seq_num) (initialised at the value 0 and incremented every time the “RECORD” layer is used) according to the following relationship:HMAC(Ki,seq_num|Type|Version Length|MESSAGE)
As previously mentioned, there are two modes for opening a TLS session called “Full Session” and “Session Resumption”.
Therefore, for example, in the case where a “Full Session” is opened, using the RSA algorithm, with mutual authentication (“Client Authentication Handshake”), between a client entity and a server entity, the client entity initiates the latter by a “ClientHello” message. The server entity responds with a set of “ServerHello”, “Certificate”, CertificateRequest”, “ServerHelloDone” messages. The client entity then sends the “Certificate”, “CertificateVerify”, “ClientKeyExchange”, ChangeCipherSpec”, and “Finished” messages.
In this procedure the client entity verifies the validity of the certificate of the server, by extracting its public RSA key, then sends to it an encrypted value called “pre_master_secret” of this key. The “master_secret” is calculated from the “Client-Random”, “Server-Random” and “pre-master-secret” elements. The “CertificateVerify” message contains a signature made using the private RSA key of the client, which proves the identity of the latter (its certificate in the “Certificate” message).
At the end of this authentication procedure, the client entity and the server entity have a new “master_secret” value from which the keys of the “keys_bloc” are deduced. A “SessionID” parameter sent within the “ServerHello” message provides an index of the “master_secret”. Then the data generated by the “APPLICATION” layer is transported by the “RECORD” entity, which guarantees the confidentiality and the integrity via the Kc and Ki keys.
When a “Session Resumption” session is opened, a previous “Full Session” procedure has already computed a “master_secret” identified by a “SessionID” index to be obtained. The authentication phase is simplified and consists for the two parties (the client entity and the server entity) of proving their knowledge of the “master_secret” value. The client entity opens the TLS session with a “ClientHello” message containing the index (“SessionID”) of a previous session. The server entity responds with a set of messages “ServerHello”, “ChangeCipherSpec”, and “Finished”. It indicates the resumption of the session by inserting a “SessionID” value into the “ServerHello” message that is identical to that contained in the “ClientHello” message. The client entity then provides the “ChangeCipherSpec”, and “Finished” messages.
The “master_secret” is not recalculated, however a new “keys_bloc” set is obtained from the “master_secret”, “ClientRandom” and “ServerRandom” elements by applying the following function:Keys_block=PRF(master_secret,“key_expansion”,server_random|client_random).
Subsequently, the data generated by the “APPLICATION” layer is transported by the “RECORD” entity, which guarantees the confidentiality and the integrity by means of the keys Kc and Ki.
The “Session Resumption” mechanism simplifies the exchange of information in a TLS session. A first “Full Session” makes the single or mutual authentication of the two ends (client and server) and creates a “master_secret”. The following sessions, based on the “Session Resumption” mechanism re-use the “master_secret” to calculate new encoding and integrity keys.
Having described the mechanisms for establishing a TLS session, two steps are highlighted for the secured exchange of information:                an authentication step permitting the master_secret to be obtained and the calculation of the session keys (keys_bloc); and        a step for transferring the information protected by the “RECORD” layer in encoded mode.        
Even though applications data is exchanged between the client and server entities, the authentication phase is the most critical process as it establishes the identity of the two parties, verifies their certificates and calculates the cryptographic keys.
One disadvantage of this technique of the prior art is related to the fact that the TLS stack (which is to say the sequence of the steps leading to the exchange of information) is entirely executed on the same computer and consequently does not permit the authentication and information exchange procedures to be separated.
Consequently there is no guarantee that the computer on which this TLS stack is executed is entirely secured and that an usurpation of keys may occur during the critical protected authentication and transfer of information phases.
Whereas many applications, for example virtual networks (VPN) based on SSL/TLS, calculation grids or overlay type networks, need specific security guarantees, in order to prevent usurpations of identity, which is to say the unauthorised use of services by computer hackers.
The complex operating systems of computers today permit the execution of malicious software such as Trojan horses, worms and viruses, which are capable of collecting the identities and RSA keys of the users.
To overcome these problems, many solutions have been proposed especially based on chip cards or external devices which contain proof of the physical identity of the user or the machine that wishes to establish a secured session (notably by the storage, on the chip card of private and public keys). Such solutions effectively permit the identity of the entity that wishes to connect to be ensured, but in no way secure the machine on which the authentication procedure is carried out.